Azure API Management Service Policy-based Logging

Info

This guide teaches how to apply a Nodinite-specific policy to enable Logging from the Azure API Management Service platform.

Why Choose Nodinite Logging Over Application Insights and Competing Solutions?

In today’s fast-paced business environments, logging and monitoring are not just about collecting data—they're about gaining actionable insights without losing valuable context. While tools like Application Insights and other logging platforms require predefined logic to capture key values (such as order numbers or correlation IDs), Nodinite Logging takes a different approach—one that eliminates guesswork, prevents data loss, and enhances long-term flexibility.

🚀 Nodinite Logging vs. Application Insights & Other Competitors

1. Full Payload Logging—No Predefined Logic Needed

• With Nodinite, you don’t need to code up-front logic to extract key values like correlation IDs, order numbers, or transaction details.
• All message payloads and context values are logged in full, ensuring you always have complete visibility into your data.
• With Application Insights and other tools, if you forget to log a value, it’s lost forever. With Nodinite, you can extract and index new fields at any time!
• Nodinite has no size restriction as is the case with many other options.

🔑 Key Advantage: No need for developers to anticipate every possible logging requirement—just log everything and extract later when the need arises.

2. Flexible Search & Reindexing – No More Data Loss

• In most competing solutions, if you realize you need a new search field, it’s too late—the data has already been logged without that key information.
• With Nodinite, you can create new search fields anytime and reindex old data without losing any historical context.
• If a field extraction was incorrect? Just fix the expression and reindex—no lost data!

🔑 Key Advantage: No risk of data loss due to changing business needs or human error in defining log fields.

3. Non-Intrusive, Policy-Based Logging

• Unlike Application Insights, which requires instrumenting your application with custom logging code, Nodinite uses a policy-based, non-intrusive approach.
• This means logging runs in parallel with your existing monitoring solutions without modifying your applications.

🔑 Key Advantage: Low performance overhead, no intrusive code changes, and complete flexibility to run alongside existing tools and policies.

4. Granular, Message-Type Level Retention

• Competing solutions often limit retention based on fixed days or data volume quotas, forcing businesses to choose between losing valuable logs or paying excessive storage fees.
• Nodinite allows you to define retention per message type, so high-value business transactions (e.g., financial transactions, critical orders) can be kept longer, while less important logs are purged earlier.

🔑 Key Advantage: Optimize retention based on business value, not arbitrary time limits or storage constraints.

🔥 The Bottom Line: Why Nodinite Wins

✅ No upfront coding needed—log everything and extract key values later.
✅ No data loss—reindex old data anytime, even if requirements change.
✅ Large payloads—log any message regardless of its size(!).
✅ Non-intrusive logging—runs in parallel with existing solutions.
✅ Granular retention control—keep critical logs longer without excessive costs.

With Nodinite, you never have to say "I wish we had logged that." Everything is available when you need it.

In this guide, there are three ways to create and send the Nodinite Log Event.

When the policy (Blob Storage Policy or Event Hub Policy) is in place and active, the code running in the Azure API Management platform creates a Nodinite-specific JSON Log Event and sends it to the intermediate storage.

The Nodinite Pickup Log Events Service Logging Agent consumes the Nodinite Log Events from the intermediate store (Event Hub or Blob Storage Container). This pattern is Asynchronous.

Tip

You can use the Nodinite Non-Events Monitoring Agent to get alerts if you have too many or too few events within a period.

Body

You can log the full payload. If you use the Blob Storage Policy, the size of the message does not matter. If it is <200KB, then you can use the Event Hub Policy. Having the payload in Nodinite has the advantage that you can use Search Fields in Log Views to create a rich user-experience on-demand for your business.

Important

When you log the payload, you must provide a name for the Message Type.

You can change the display of the body using Stylesheets. This is a cute trick to hide content. You can use the Role-based security to apply who can access what and who gets to see what.

Context

A Nodinite Log Event supports the use of a Context; A collection of key-value pairs. In addition with the existing HTTP Headers in the call, you can have additional properties in the Logging policy. You can later use these to create the set of Search Fields of interest for use in self-service enabled Log Views.

Request Headers	Response Headers

Tip

You can add to the code in your policy exactly what properties are included in the Logging.

If you happen to log to much, you may want to tweak the following System Parameter:

• ContextPropertiesFilters

Obviously since you have full control of the Logging in the Policy, you can determine up-front what to include in the Logging.

Troubleshooting

Contact our Support for additional guidance if you fail to implement the Logging.

Logging Options

In the diagram below you can find the many different options for Logging from Azure to Nodinite.

If the target for logging from the API policy is an Event Hub entity; The named Event Hub entity CAN be re-used if the content logged, is a Nodinite JSON Log Event.

Important

EH1, EH2 and EH3 MUST have each own syncpoint (bookmark), i.e. one blob storage container for each event hub entity and client.

• If possible, please use the Blob Storage Policy as it has less administration and provides large messaging support.
• Logging from Azure functions can share the same Eventy Hub as APIM, if the Log Event is a Nodinite JSON Log Event.
• Logging from Azure Logic Apps requires one or more OTHER event hubs as target since the content is in a different format.

Using a shared Event Hub for a Nodinite JSON Log Event has the advantage of less administration (i.e. you must configure the Nodinite Pickup Log Events Service Logging Agent to fetch these events)
The disadvantage can be performance-related, or other factors should be considered like pricing (logging from multiple regions), scalability, retention settings, number of partitions, ...

Tip

Make sure to use separate event hub entities for different purposes and needs, i.e. multiple Logic App Logging, multiple API management Services, multiple APIs, multiple Azure functions, all according to your architecture.

Important

You MUST NOT use the same Event Hub Entity for Logic Apps Logging as for the Serilog and Policy based solutions. This is because the diagnostics from Logic Apps are from Microsoft and all the other creates a Nodinite JSON Log Event. These can not appear on the same Event Hub Entity, EVER.

Next Step

Pickup Log Events Service Logging Agent
Azure Application Access

Related Topics

JSON Log Event
Managing
Monitoring
Non Events Agent
Stylesheets

Interested in logging from other Azure Related Services?

• Logging from Azure Logic Apps
• Logging from Azure functions